Don't try to label ObligationCauseCode::CompareImplItem for an RPITIT, since it has no name
#127404
Conversation
rustbot
added
S-waiting-on-review
This comment has been minimized.
This comment has been minimized.
|
yeah im just gonna delete the test since it's not particularly interesting |
…, since it has no name
compiler-errors
force-pushed
the
rpitit-entailment-false-positive
branch
from
9cf41da to
d6276b3
Compare
|
@bors r=oli-obk rollup |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
|
Finished benchmarking commit (9e27377): comparison URL. Overall result: ❌✅ regressions and improvements - no action needed@rustbot label: -perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)Results (secondary -1.2%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResults (secondary -0.5%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 699.359s -> 699.372s (0.00%) |
The old (current) trait solver has a limitation that when a where clause in param-env must be normalized using the same where clause, then we get spurious errors in
normalize_param_env_or_error. I don't think there's an issue tracking it, but it's the root cause for many of the "fixed-by-next-solver" labeled issues.Specifically, these errors may occur when checking predicate entailment of the GAT that comes out of desugaring RPITITs. Since we use
ObligationCauseCode::CompareImplItemfor these predicates, we try callingitem_nameon an RPITIT which fails, since the RPITIT has no name.We simply suppress this logic when we're reporting a predicate entailment error for an RPITIT. RPITITs should never have predicate entailment errors, by construction, but they may due to this bug in the old solver.
Addresses the ICE in #127331, though doesn't fix the underlying issue (which is fundamental to the old solver).
r? types